…ime in CI

Reduce 19 hard-coded waits across in-PR-scope helpers and specs without
changing what they wait for or removing the annotated reasons. The
biggest single win is utils/lineage.ts dragAndDropNode (1000→300ms),
which fires ~225 times in DataAssetLineage.spec.ts and recovers ~2.5min
on that file alone.

Scale used: 2000→500, 1000→300, 500→200, with conservative caps on
pipeline-deployment waits (5000→2000) since those have real backend
settling time. Promise.race race-cap timeouts (widgetFilters,
customizeLandingPage line 513) are left untouched — those are response
deadlines, not sleeps.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…s project

CustomProperties.spec.ts (3862 lines, 476 tests, ~193 min test-time) and
DataAssetLineage.spec.ts (557 lines, ~69 min) ran the same UI flow for
19 and 15 entity types respectively — redundant safeguards on every PR.
Split each into a shared helper + thin entry files so PR runs only the
representative entity (Table) plus Dashboard's unique advanced-search
coverage; the other entities now run in a new `stress` project triggered
manually via postgresql-nightly-e2e.yml (workflow_dispatch). Nightly
itself and the existing nightly/ folder are untouched.

PR runs:
  - Pages/TableCustomProperty.spec.ts       (Table CRUD + name validation)
  - Pages/DashboardAdvanceSearchCustomProperty.spec.ts  (Dashboard full)
  - Pages/Lineage/TableLineage.spec.ts      (Table parameterized + 3 unparameterized describes)

Stress runs (manual via workflow_dispatch):
  - stress/CustomPropertiesAllEntities.spec.ts          (17 other entities)
  - stress/Lineage/DataAssetLineageAllEntities.spec.ts  (14 other entities)

Estimated max-shard impact: shard 4 drops from ~141 min to ~85 min
(CustomProperties wall-time down from ~64 min to ~20 min on PR), shard
6 drops from ~124 min to ~109 min (DataAssetLineage down to Table-only).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…l to 7

Apply the same shard 7 stress addition to mysql-nightly that was added to
postgresql-nightly in the prior commit. Also bump shardTotal from 6 to 7
in both files so the matrix metadata matches the actual entry count
(shardTotal is unused by the run command — --shard=N/5 is hardcoded — but
the stale 6 was misleading).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two tests in this file sleep on intentional JWT-expiry waits (3 min and
~2 min via waitForTimeout). With the global retries:1, a single flake
under one of those tests would relive the same 3- or 2-min sleep before
reporting — ~5 min of waste per failed retry. Token-expiry failures are
almost always real (config drift / token TTL mismatch), not transient
flakes, so retrying buys nothing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…2e-ci

…metadata/OpenMetadata into optimize-playwright-e2e-ci

…e responses

The test 'Table pagination with sorting should works' was failing on
both attempts in CI with `expected: 15, received: 0`. Root cause: the
test clicks 'Name' to sort, then clicks 'next' to paginate, then
asserts row count — but it only waits for `waitForAllLoadersToDisappear`
between actions. The loader for the current page can finish before the
new page-2 fetch arrives, leaving the assertion to run on an empty
table mid-transition.

Two changes:
- Register `waitForResponse('/api/v1/dataQuality/testCases/search/list?*')`
  before both the sort click and the next-page click, so the test waits
  for the new data to land.
- Replace `expect(... count() === 15).toBe(15)` with
  `expect(locator).toHaveCount(15)`, which auto-retries until the
  table re-renders.

Exposed by the move from retries:2 → retries:1; was passing on 3rd
attempt before.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…rt flakes

4 of the 7 flake-on-retry tests from the latest CI run are the same ES
indexing race as BulkEditEntity:661 (already fixed in 860e875): the
test creates entities via API, then immediately opens a bulk-edit or
bulk-import view that reads from ES. The ES indexing lag races the test.

Added waitForSearchIndexed after each API-create:

- BulkEditOperationBadges.spec.ts beforeAll: term + table indexed before
  any of the 4 tests in the file runs
- BulkImport.spec.ts:
  - Database service test → database_service_search_index
  - Database Schema test → database_schema_search_index
  - Table test → table_search_index

ContextCenterPermission Archive (1433, 1506) and DataQualityDashboard
Data Product (1021) flakes are transient backend slowness — pass on
retry; not deterministic test bugs to fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…2e-ci

…xing

The 'Admin: Complete export-import-validate flow' test was failing on
both attempts with:
  Expected: "5"
  Received: "4"
on the `processed-row` assertion.

Root cause: same ES indexing race pattern. The beforeAll creates the
table + one test case via API, then `performE2EExportImportFlow`
exports the table's test cases via search. Without waiting for the
just-created test case to be indexed, the export's CSV is missing the
1 existing test case row, so 4 added rows = 4 processed (not the
expected 5 = 1 existing + 4 added).

Added `waitForSearchIndexed(... test_case_search_index)` after
`table.createTestCase()` in both the Admin and EditAll User describes.

Also: re-ran organize-imports + prettier on BulkEditEntity.spec.ts to
fix the UI Checkstyle Playwright-lint job — the prior commit's manual
edit left the file out of the formatting sequence.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…r grid render

Both genuine failures in the latest CI run (BulkImport.spec.ts:154 and
:614) failed at `expect('.rdg-cell-details').toContainText(rowStatus)`.

From the retry log, the result grid IS populating but slowly — on retry
the helper observed `3 × locator resolved to 0 elements` then
`16 × locator resolved to 2 elements` while the test expected 6 cells.
The assertion was running against a mid-render grid and never caught up
within 15s (the default expect timeout).

Made the helper a two-step wait: first `toHaveCount(rowStatus.length)`
with a 60s timeout so the grid finishes rendering all rows, then the
existing `toContainText` against the populated cells. This avoids the
race without changing what the assertion checks.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two waits I tightened in the earlier sweep had non-obvious correctness
implications that two reviewers (greptile-apps, gitar-bot) flagged.
Reverting both to 2000ms.

1. auth.setup.ts:208 (500→2000ms):
   This is the only guard between the indexedDB API being available and
   the storageState snapshot being written. waitForFunction confirms the
   API exists but not that auth data has been persisted. A miss here
   corrupts admin.json and cascade-fails every downstream spec that uses
   `test.use({ storageState: 'playwright/.auth/admin.json' })` — and with
   retries:1 the blast radius is larger than it would have been before.
   The 1.5s saved × 6 shards is negligible vs that risk.

2. CustomThemeConfig.spec.ts:207 (500→2000ms):
   This is the rare wait that IS the test's assertion-observation window:
   the assertion `monogramCallCount <= 1` is only meaningful for the
   duration the test sits and watches for late requests. At 500ms a
   duplicate monogram request arriving 500ms-2000ms after save would not
   be counted, so the test could pass while the regression it guards
   against is present (false negative). Added an inline comment so a
   future me doesn't re-tighten this.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…res/pages

`support/fixtures/userPages.ts` defined 7 storage-state-keyed Page
fixtures (adminPage, dataConsumerPage, dataStewardPage, ownerPage,
editDescriptionPage, editTagsPage, editGlossaryTermPage). All 7
overlapped with `e2e/fixtures/pages.ts`, which already had 8 of the
same fixtures (incl. viewOnlyPage) plus an `adminPage`-equivalent
override of the default `page` fixture. The only meaningful difference
was that userPages used `browser.newContext()` + `context.newPage()`
while pages.ts uses `browser.newPage()` — functionally equivalent
since `newPage()` creates a context under the hood.

Usage breakdown was 66 specs on pages.ts vs 8 specs on userPages.ts,
so userPages.ts was the duplicate to remove.

Changes:
- Added explicit `adminPage` alias to pages.ts (returns same admin-storage
  page as the default `page` fixture) so migrating specs don't need to
  rename call-sites
- Re-exported `expect` from pages.ts (matches userPages's surface)
- Updated 8 specs to import from `e2e/fixtures/pages` instead of
  `support/fixtures/userPages`
- Deleted `support/fixtures/userPages.ts`

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…stomThemeConfig

In commit a4a346e I added a multi-line explanatory comment above the
2-second monogram-observation wait, which inadvertently pushed the
`// eslint-disable-next-line playwright/no-wait-for-timeout` directive
several lines up from the actual `await page.waitForTimeout(2000)` call.
`eslint-disable-next-line` only applies to the immediately following
line, so the rule fired and the Playwright lint job failed.

Moved the disable comment back to be adjacent to the waitForTimeout,
with the explanation block kept above it (no other content changed).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…tive assertion

ExploreBrowse.spec.ts:255 (service type drill-down):
The test calls expandTreeNode('Databases'), then clicks
explore-tree-title-mysql. expandTreeNode only waits for loaders to
disappear, but the tree's child rows keep animating/repositioning for
a beat after that. The subsequent .click() then times out with
"waiting for element to be visible, enabled and stable".
Added an explicit `await expect(serviceTitle).toBeVisible()` before
the click; toBeVisible polls until the element is stable, which lets
the click land cleanly.

SearchRBAC negative assertion (utils/searchRBAC.ts, exploreShouldShowEntity):
The "fully denied user sees neither asset type" test consistently saw
1 element across 18 retries (~15s) — both initial and retry attempts
ran ~30s and failed. Root cause: RBAC enforcement against a
newly-assigned user role lags the patch call by several seconds while
the search-index user doc updates. The default 15s expect-timeout for
the toHaveCount(0) assertion isn't enough for the result-card to drop
out as the role takes effect.
Extended the negative-assertion timeout to 45s. The positive-assertion
case (shouldSee=true) keeps the default — it only ever needs to see
the entity once, not wait for it to disappear.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…2e-ci

…specificity

3 genuine failures (failed both attempts) from latest CI:

DescriptionSuggestion.spec.ts:326 and TagsSuggestion.spec.ts:526 share
the same root cause in utils/taskWorkflow.ts:openTaskDetails — the test
creates a task via API, then opens the entity's tasks tab and expects
the new task card to be visible within 15s. Under Basic-project
parallelism the activity-feed UI refresh lags past 15s and the card
never appears within the default timeout. Bumped openTaskDetails'
toBeVisible timeout from 15s to 45s — healthy runs aren't affected
since toBeVisible polls and resolves as soon as the card appears.

SearchIndexNestedColumns.spec.ts:109 — `waitForResponse('/api/v1/search/query?*')`
was racing with the empty-query suggestion fetch fired when the search
box is clicked. The test's listener would resolve on that earlier
response and then check for the suggestion dropdown before the
table-name query had even fired. Made both waitForResponse patterns
predicate-based so they match only the response whose URL contains the
encoded search term.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…test

After three CI iterations on retries:1 the same root cause kept
surfacing in different tests each run (task-feed UI not refreshing
within 45s after API task create, RBAC index propagation, search
dropdowns racing the empty-query suggestion response, etc.). Each one
takes its own diagnosis round and the failing set rotates, so we can't
land the PR by fixing them one at a time.

Restoring retries:2. The rest of the PR's wins stay:
- maxFailures:50 still bails fundamentally broken PRs in minutes
  rather than running the full ~2h35m suite
- The PR↔stress split still cuts ~20% off worst-case PR shard time
- Wait-time tightenings stay (the bad ones were already reverted)
- ES-indexing-race fixes (waitForSearchIndexed in BulkEdit,
  BulkImport, TestCaseImportExport, etc.) stay — those were real
  bugs, not retry-masked flakes
- Spec-side fixes (Roles loader, SearchRBAC waitForResponse,
  exploreTreeCategories poll, Domains setTimeout cap, ContextCenter
  CSS regex, Table.spec pagination wait, etc.) all stay

Net effect: PR still ships meaningful CI improvements; we just don't
pretend we can drop a retry for free against a flaky baseline.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>